fix(launcher): make CLI sign-in and installs work off the machine's real environment - #659

Four reported failures that turned out to share one shape: something the launcher spawns could not see the environment it needed, and the check that should have caught it looked somewhere else and passed.

1. CodeBuddy signs into the wrong site

The CLI fronts two separate services — codebuddy.ai / workbuddy.ai and codebuddy.cn / workbuddy.cn — and keeps one session on disk, selected by CODEBUDDY_INTERNET_ENVIRONMENT.

The sign-in terminal opened bare, so it always signed in against the international site. An agent configured for the China site then ran with the variable pinned to internal and failed auth on every message, with a terminal that had just said "logged in". The reporter's screenshot showed the session running Hy4 preview, a model that only exists in the international product.json.

The sign-in terminal — and the per-agent Chat terminal, which is the agent's own CLI — now carry the same value the adapter overlays on the agent's runs. international deliberately pins nothing: unset is the CLI's documented default and what lets its startup follow the session on disk, and there is no product.external.json to select.

2. ...and a completed sign-in could never be confirmed

codebuddy had no probe at all, so verifyLogin returned false however the login went and the poll gave up after five minutes.

It joins DUAL_LOGIN_AGENTS with a creds-file probe reading the session file /login writes — the CLI's extension data directory, on all three platforms, named after the authentication.id in its product.json.

Because that one file covers every site, a new credsGuard hook checks the session's own domain against the configured region. Without it the probe would trade one wrong answer for another: a session for the other site would read as a green Ready in front of an agent that cannot authenticate. Only auth / auth.domain are read; the token in the same file is never touched.

3. The sign-in terminal went direct while the browser used the proxy

Reported as Client network socket disconnected before secure TLS connection was established, on a machine whose browser had just reported the login as successful.

On macOS the sign-in terminal is not our child — osascript hands a script to the already-running Terminal.app — so it never saw the proxy this process had resolved from System Settings. This is the same gap adoptSystemProxyForChildren documents for kimi login, and it was only ever closed for the in-app piped path. The terminal-only CLIs (codebuddy, gemini, hermes) were the ones still exposed.

proxyEnvForChildren() now writes it into the terminal script, both spellings, with the user's own bypass list preserved and 127.0.0.1 (where these sign-ins complete) kept off the tunnel.

4. Installs could not find a user-installed tool

OpenWorker installs with uv tool install, uv's own installer puts the binary in ~/.local/bin, and a GUI process inherits a shell-less PATH.

The two sides disagreed: install-preflight.js's probeUv searches ~/.local/bin and passed, then installer.js's _buildShellEnv — which only added /usr/local/bin and /opt/homebrew/bin — spawned /bin/sh -c "uv tool install …" and got exit 127. The guard passed and the thing it was guarding failed, which is the worst of both answers.

Both sides now agree. The launcher restores the user bin dirs on its own PATH at startup (appended, so anything the user configured still wins), and the core adds them to _buildShellEnv as a last-resort fallback — unshift, because that loop prepends, and these must never shadow the runtime directories.

Also fixed while in here

• runTerminal's Linux branch dropped extraEnv entirely, so Gemini's workspace trust and CodeBuddy's site pinning never reached a Linux terminal.
• Command Code's probe read whoami, which reports an unreachable account service as Error: Connection error. on a clean exit — indistinguishable from success under negative-only matching, so an offline machine read as signed in. It now reads status, the CLI's own authentication check, with both directions named so an offline machine stays "unknown" rather than getting a wrong verdict.
• CODEBUDDY_AUTH_TOKEN counts as configured credentials. The registry lists it beside the API key as a first-class auth path, but it is not an *_API_KEY, so a token-configured agent read "Login required".
• OpenWorker's keyless providers (ollama, openai-codex) no longer read "No model API key" for as long as they run; openai-codex is labelled as the CLI sign-in it actually is.
• _savedTypeEnvForProbe reads the connector's raw agent list rather than getAgents() — that path derives health, health asks the sign-in probe, and the probe would have landed back there, recursing on every dual-login agent.

Scope

The core change (installer.js) only reaches users when @openagents-org/agent-launcher next ships; the launcher-side PATH repair fixes the OpenWorker install on its own against the pinned 0.2.177.

One case is deliberately not covered: a machine with no proxy configured anywhere that simply cannot reach www.codebuddy.ai. Nothing here can fix that — the answer is the China site, or a proxy in Settings → Network, which now reaches the login terminal.

Verification

• launcher: typecheck clean, 476 tests (30 new — site mapping, session/region agreement, proxy hand-off, PATH repair, commandcode's three states, keyless providers, CODEBUDDY_AUTH_TOKEN)
• agent-connector: 1512 tests
• release notes validated; launcher bumped to 0.9.27

Anyone who signed in to CodeBuddy before this release should sign in once more from the Login button — the existing session may belong to the other site.

🤖 Generated with Claude Code